EMP Pre-Screening Payments
This RFC describes the solution to integrate the Pre-Screening Payments into Ebury Mass Payments environment.
Abbreviations, acronyms, and definitions
- Ebury Core or Core: Current Ebury production data, infrastructure and services.
- EMP, Ebury Mass Payments or Mass payments: Current Ebury mass payments production data and services.
Problem Description
Currently Ebury Mass Payment does the screening of a payment on the execution date which is not ideal once the team don't have enough time to clear any sanction exceptions.
The large volume of payment is concentrated at the end of the month, which worsens the problem of not having enough time to clear any sanction exceptions.
Some of the work is done by a manual process like updating AML Status on BOS.
Background
Pre-screening is a new feature that allows payments to be sent for screening before payment execution date and before prepayment funding and authorisation is completed. The team will then have time to clear any sanction exceptions prior to execution date so that a 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.
Some examples
The CSI team had worked on some tasks following this RFC EMP AML Migration to implement the logic of pre-screening for EMP in the BOS code inside the Ebury Core environment. Considering the migration of Databases from EMP to CORE which had its scope changed and will no longer be performed. Related tests here.
The implementation of pre-screening was applied in this periodic task on BOS Code which will decide with some switches when a payment should be screened.
Which means that we can use that implementation with some small changes in the code to provide the pre-screening in the EMP.
Solution
In order to have the Pre-Screening in the EMP working with Lexis Nexis we should do some changes:
- Adjustment in the BOS code and some switch configurations to execute the pre-screening in the expected timing.
- Revert pre-screening implementation related to the database migration of EMP.
- Create an exclusive periodic task for each environment EMP and Ebury Core.
- Configuration of pooling on the Sherlock to get the AML status updated without the need of a manual click on the button check AML.
- Verify the capacity of infrastructure related with the pooling in order to identify if it will be required to scale the infrastructure.
- Adjustments in Sherlock code configured for EMP(EMP has a specific contract of LexisNexis and will be required to execute other queries different from Ebury Core).
- Additional tests activity of volume spikes with Sherlock.
- Create a document like this one for EMP in order to have a place to hold the logic for screening.
- Implement a logic in Sherlock to execute queries exclusively for each environment EMP and Ebury Core.
The final solution will look like this
Caveats
None
Operation
Operations Team will have a reduction of manual work and also will have more time to handle any sanction exceptions.
Security Impact
No impact on the security once the solution will only change the timing of the screening.
Performance Impact
With the implementation of pre screening we will increase the amount of screening since we can do at least one more screening than the usual, however these processes will be distributed in fewer requests per day, between the interval of creation of the payment to the day of execution, so instead do all screening in one day we gonna split it in the interval of all payments.
Developer Impact
The CSI team will need to maintain two instances of Sherlock with different business rules for each environment where each one will have its own demand.
Then one must think of a solution that minimizes the possibility of error or exchange of rules between the two instances.
Dependencies
We will need the deploy of Sherlock on EMP which will be achieved with this RFC to be able to implement the pre-screening feature.