Ebury Mass Payments Migration - AML Capabilities
Background
There are two Ebury environments, and each one of them has different AML capabilities. One environment is the usual core environment that most teams are working on, but the Ebury Mass Payment (EMP) teams use another.
In the context of this document, the AML capabilities will be split into two different sets:
- Payment Screening: features to compare payment data against pre-existing lists - for example, PEPs and Sanctions.
- Transaction monitoring: features to monitor payments based on rules or activity patterns - for example, payment to a restricted country.
Onboarding screening is not listed because we already migrated the flow to use a single Salesforce environment.
Providers
There are two different providers used by the AML features: LexisNexis (v4 and v5) and ComplyAdvantage.
Problem Description
The Mass Payments team uses a different set of features from the Core team, and there are also differences in the AML flow of each of the teams.
The goal is to have one environment and migrate the Mass Payment capabilities to the Ebury Core environment.
Feature Mapping
New feature - Pre-screening
A new feature that allows payments to be sent for screening before payment execution date (and potentially before prepayment funding and authorisation is completed). Hence EMP (Ebury Mass Payment) team will then have time to clear any sanction exceptions prior to execution date so that very few exceptions will be raised on the final payment day screening.
Therefore, we should have the ability to send the payments on the payment date but also before it.
Out of Scope
It has been already aligned that the following two features are out of the scope of the AML capabilities.
Legal Entity Mapping
It is not part of this initiative to solve how we will map the brands inside BOS, including payments and AML related entities - for example, to answer questions like the ones below:
- How will we differentiate payments inside BOS?
- How will we differentiate AML entities (Clients, Contacts, Beneficiaries, etc.) in BOS?
Why is it out of scope? Because it is already part of the data migration effort to provide a solution for it.
Where will those details be covered? As a result of the data migration effort, appropriate epic(s) will be created.
User Experience Enhancements
We are not going to handle UI changes in BOS as part of this RFC.
Why is it out of scope? The brand filter is already supported in the AML related queues, and other changes outside the AML domain are needed to provide a better experience for the EMP users.
Where will those details be covered? There is one epic (EMP UI Changes to enable Migration) already approved to handle this changes.
Solution
The solution is based on several functionalities that are implemented in the Ebury Core environment. In the context of this document, we will explore all the changes that are needed.
Third Party Screening
There is a minimal number of third parties introduced in the Mass Payments environment, and all the screening is performed manually by the team with LexisNexis v5.
Changes
None from a technical perspective - third party screening will follow the core process to use ComplyAdvantage for that and not LexisNexis.
Payment Data Screening
The environments use two different LexisNexis versions. The team is working to remove the FXSuite dependency and have screening handled by Sherlock - this is a dependency for the success of this feature.
The Sherlock data model already supports the notion of a provider, and it will be already supporting the integration with LexisNexis v4. Also, the new API version of LexisNexis v5 is backwards compatible with the previous version - including all the payloads.
Finally, both versions are already up and running and integrated with FXSuite - which decreases the complexity by one order of magnitude if you compare it to a new integration from scratch.
Changes
It is important to recap that both LexisNexis versions work in the same way from integration and technical perspectives.
Inside Sherlock, we should use a new provider (LexisNexis v5) to share the existing LexisNexisController to handle the screening requests. So, we can have different credentials and versions reusing the same infrastructure.
After that, inside BOS (or another client), when requesting an entity to be screened by Sherlock, one option is to set a provider field that is already supported:
{
'action': 'search',
'entity_type': 'client',
'provider': 'Lexis Nexis v5',
}
Therefore, we can set the provider of the request to either Lexis Nexis or Lexis Nexis v5 based on the brand of the payment in the context.
Another option would be to abstract the provider by adding the brand support directly into the request to Sherlock:
{
'action': 'search',
'entity_type': 'client',
'master_brand': 'Ebury Core | Ebury Mass Payments',
}
Finally, we have to update the feedback flow from Sherlock to use the LexisNexis infrastructure whenever the provider used was LexisNexis, regardless of the version.
Real-time Transaction Monitoring
The daemon TransactionMonitoringSendingRequestDaemon in BOS is sending all the eligible payments to Sherlock real-time monitoring.
Changes
Given that we do not want to have it for Mass Payments, we could update the payment query set PaymentQuerySet to do not consider payments from Mass Payments to be eligible. Currently, the query below is used:
def ready_for_transaction_monitoring(self):
...
return (
self.in_hold_queue()
.beneficiary_authorised()
.transaction_monitoring_not_checked()
.value_date_before(tomorrow)
.beneficiary_not_blocked()
.workflow_ready()
)
Retrospective Transaction Monitoring
Daily, BOS generates a report to be manually uploaded in the ComplyAdvantage TM platform to perform the transaction monitoring.
A celery task ComplyAdvantagePaidOnDailyReport is already created and configured to generate different reports based on the environment that BOS is running. Also, the reporting infrastructure (reports/controllers/comply_advantage) is considering the other fields to generate.
Changes
Given that using the utils.get_master_brand() is not an option anymore, we could generate two different reports, each one already based on a brand and filtering out the payments related to it.
Finally, we can have the same command call generating the reports or two different commands scheduled with different params.
Pre-screening
Every 2 minutes, a command (operations/management/commands/aml_send_payments.py) in BOS sends the eligible payments to be screened. The criteria to select the payments is complex, but the important part is that we are just going to screen payments with a value date equal or less than today.
There are moments that this is not feasible for the Mass Payments team, given that they may not have enough time to go through all the payment hits. So, we will introduce the option to send the payment to screening as soon as it is manually funded, regardless of the value date.
Changes
The first step is to have one additional flow sending the payments to Sherlock (or FXSuite). One of the flows will consider all payments with the current logic, and another one will consider just Ebury Mass Payments payments for pre-screening. It is an open but still valid discussion whether we will have a separate task scheduled or use the same one to perform both flows.
Finally, we have to update the payment criteria for the Ebury Mass Payments flow to ignore the value date criteria. We also have to avoid sending the same payment twice on the same day.
BOS Switches
There are a few legacy switches inside BOS related to the fact that we don't have Sherlock deployed to the current EMP environment. For the migration, we should not change any of the switches in BOS, keeping its current state - all necessary changes should be applied in the different flows defined in the features above in this document.
FAQ
- Why we do not want to enable real-time transaction monitoring for Mass Payments? A: They have a different set of rules on another platform.
- Why we do not move Ebury Core to use LexisNexis v5? A: It is already planned.
Operation
There is an impact on how operations will handle the AML flows between the two environments, but this is not in the scope of this document.
Security Impact
The setup of different access permissions to manage Ebury Core or Ebury Mass Payments payments is out of scope.
Performance Impact
We expect the number of payments to increase considerably. Although the asynchronous request model that Sherlock supports should be prepared to handle the workload, it is part of this initiative to run the performance tests.
We should handle 10x more entities to be screened and 10x more payments in the transaction monitoring flow. Also, we have to show that the feedback flow inside BOS can handle this amount of workload.
A few more items to consider:
- The interval between the periodic tasks inside BOS with the new workload.
- The number of resources available for the daemons and Sherlock itself.
- The storage limitations of side-effects like the certificate uploading to Google Drive.
- The database data access patterns and indexing.
Dependencies
- Assumption that we can correctly and efficiently discriminate payments/entities from Core and Mass Payments.
- It will be possible to support multiple LexisNexis versions after we finish removing screening from FXSuite.