Incoming funds screening flow

Background

Currently, we are screening information related to Third Parties (name and trading name) when we have a reconciled incoming fund.

As part of the new compliance requirements, we have to extend the screening ability to consider fields related to the fund itself, represented by the bank account entry in our domain.

The fields that we have to screen are:

The ordering address.
The ordering bank account information from the third party.
The ordering bank account information from the first party.

You can see in the image below the whole reconciliation flow with the screening taking place on your left:

High Level Current System

Third party

A third party entity is a company or an individual sending money to an Ebury's client from an external account.

First party

The first party entity is similar to the third party, with the difference that it is the client itself sending money to its own Ebury account.

Currently, the first party entity is not part of our domain model inside BOS - the information is available in the bank account entry but not used.

Problem Description

The new fields to be screened are part of the bank account entry inside BOS and not part of the Third Party entity like the other fields (name and trading name).

We can't just enhance the Third Party entity with the additional fields because we would not be able to cover the scenarios below:

First party bank account information.
Third parties can be linked to multiple bank account entries with different bank account information and addresses.

Solution

The AML logic related to incoming funds assumes that we only have to check the third party information. This assumption does not stand given the new screening requirements that have to be adopted along with upgrading to LexisNexis v5.

A better option is to introduce a new screening flow for incoming funds that can handle additional fields, e.g. first party and bank account information.

Outline

The current entry points and AML response handling in BOS are tangled with the FxSuite implementation (e.g. circular imports). The data formats are not ideal for multi-level entities (Payment, ReconMatch). We can use to our advantage the fact that the new incoming funds flow does not have to be backwards compatible with FxSuite/MP.

The solution implies creating a more generalized version of the current screening flow that can handle the incoming funds in parallel with the existing code. Initially, the new flow will be used just for IncomingFunds under the LexisNexis V5 switch, and then the other screening flows will be gradually migrated.

The work is split into two different phases:

Introduce the new flow and use it for incoming client funds only.
Add the legacy entities to the new flow gradually.

We are not changing the persistence layer inside Sherlock, just the domain model to accommodate the new flow.

Testing

We have already created the testing suite to drive the development from an integrated/high-level perspective:

Phase 1 - Introduce the new flow and use it for incoming funds only.

The goal is to improve the contracts between the components (BOS and Sherlock) and add new code paths to support these new formats.

The contract between BOS and Sherlock in the feed-forward flow will be very similar to the current one. The main difference is that we will not use the concept of a provider anymore - Sherlock will be responsible for that based on the request's origin.

Example:

{
    object: ReconMatch,
    origin: bos_core,
    reference: RM1112,
    bank_account_entry: {
        reference: BAE1234,
        remittance_information: …,
        address_ordering: …,
    }
    third_party: {
        name: str,
        country: str,
        trading_name: str,
        ...
    }
}

Then, in the example below, you can see the new approach in the way that Sherlock will be sending the response back to BOS:

{
    object: list,
    data: [
        {
            object: AmlResult,
            reference: RM1112,
            aml_status: "No match",         
        },
        {
            object:AmlResult,
            reference: THI1234,
            aml_status: "No match",
        }
    ]
}

Note: the payloads are illustrative; we may change them during the development.

Code changes in BOS

We have to follow the steps below to accomplish the goal inside BOS:

Update the ReconMatch domain model to add the AML status indication - we will evaluate how we are going to change the persistance layer, given the ~10 million records there.
Add a new serializer for the ReconMatch model.
Introduce a new screening entry point inside the ScreeningFacade.
Introduce a new switch in BOS.
Update the reconciliation process to trigger the new AML flow if the switch is active.
Update the reconciliation process to use the AML status under the authorization process.
Update the feedback flow from Sherlock to handle the reconciliation status changes.
Update the user experience to display the new flow.

You can look at the references for a detailed view of the code changes.

Code changes in Sherlock

Inside Sherlock, we will perform the steps below:

Handle the new message format from BOS.
Process the new message format from BOS in the internal consumer.
Screen the fields using LexisNexis.
Update the AML response for the new ReconMatch object.
The AML polling should not be impacted, but we must add more tests with the new objects.

Phase 2 - Refactor the existing flows

Once we have finished the compliance requirements, we should migrate the legacy flows to the new one. This will enable us to move much faster and start thinking about the following stages for Sherlock and screening.

We will handle it as technical debt, and it is not going to be on the critical path for the team, but it should be started right away to get the most efficiency out of it.

Alternatives

Amend the third party screening flow

At first sight, it seems a good idea to enhance the current third party flow and send the reconciliation match object together to be screened.

We would update the current (and fragile) flow inside BOS and send the additional information. However, it would not solve the problem reliably:

We still need the AML status in the reconciliation match itself - not only in the Third Party.
We need to support two different flows using the same screening infrastructure: third parties and third parties with reconciliation matches.
We need to support two of Sherlock's feedback flows in the same screening context.

Finally, we have more non-functional challenges related to the approach below:

The new flow should be enabled just for LexisNexis v5, which means we can introduce bugs in the current AML flow.
We will have to add "switch" based decisions in BOS and inside Sherlock in many different places.
The testing infrastructure will be more fragile with all the complexity introduced by the switches and the legacy code.
We are still tight to the legacy AML flows inside BOS and Sherlock.
If there is an additional screen requirement, for example, another entity, we would need to replicate the whole mess again.
The degree of parallelism achieved with this solution is low - the code is highly coupled.

Create a new third party for each bank account entry

Another alternative would be to replicate the same behaviour with beneficiaries: duplicate the third party entity for as many reconciliation matches as we want to screen.

To achieve this solution, we would need to copy the existing data from the reconciliation match object to the Third Party information and change the user experience that the teams have.

Although this is, by design, an inadequate solution, we are discarding this by the simple fact that it would impact other teams outside the AML domain, and it does not solve the problem for the first parties.

Operation

As part of the proposed solution, it has already covered the screening team's user experience impact.

Security Impact

None.

Performance Impact

We do not expect any performance impact - given that we already screen the third party information for the reconciliation match objects.

Dependencies