Removing Screening from FXS

Background

Currently, we work with two screening third party services:

  • ComplyAdvantage (hereinafter Comply when abbreviated)
  • LexisNexis (hereinafter LxNx when abbreviated)

Through these services, we check the entities associated with incoming funds and outgoing payments, such as clients, beneficiaries, and client third parties, in order to comply with current laws regarding AML and sanctions.

Problem Description

We do not have a centralized system for the screening process:

  • ComplyAdvantage is handled by Sherlock service.
  • LexisNexis is handled by FxSuite service.

This causes some complexities in our system:

  • Client applications (BOS, Salesforce) require a different connector for each of the external services.
  • The data and business logic related to screening are on two different platforms without any relationship.
  • If one of the two services goes down, the switch between using Comply or using LexisNexis must be managed in each of the clients, having to change settings in both salesforce and BOS.
  • In the case of LexisNexis, are the clients themselves that have implemented a polling mechanism to know if any entity has changed state, when this should be the responsibility of the screening service that asynchronously notifies that information.
  • The only dependency that exists between Salesforce and FxSuite is the AML check.

In addition, the AML management through LexisNexis is carried out in the FxSuite application, with versions of python and django out of support, using poorly structured code and almost no documentation.

At a very high level, this is the current system:

High Level Current System

Solution

Move the LexisNexis management from FxSuite to the Sherlock ecosystem, providing it with updated technology and a structure that allows the unified management of both providers (Comply and LxNx).

For this, we have defined 3 phases that will reduce the risk of undertaking too many changes at the same time.

Phase 1

Main objective: paving the way for the changes to come.

To do this, Sherlock will act as a proxy when making requests to FxSuite-LxNx from BOS or Salesforce, so that they will send and receive the same information but over a different technology.

Therefore we will go from having this architecture diagram (split by providers for greater readability):

ComplyAdvantage

ComplyAdvantage Current System

LexisNexis

LexisNexis Current System

To this other:

ComplyAdvantage and LexisNexis

Phase One

So we can move capabilities from Fx Suite to Sherlock incrementally and in a safer way, as we will see in the next phase.

Applications that perform AML checks will need to make certain changes:

  • Adapt the LexisNexis connectors in BOS and Salesforce to connect to Sherlock in the same way that they currently do to query ComplyAdvantage, that is, using SQS / SNS, as we can see in the previous diagram.
  • Review the BOS pages where a synchronous response from LexisNexis is expected to show the AML state through the interface, as now the response will be returned asynchronously:
    • Check AML of a beneficiary from list and detail page
    • Check AML of a payment from list and detail page
    • Create and edit beneficiaries

Phase 2

Main objective: perform the AML check always through Sherlock, stop using FxSuite for it.

This is the architecture diagram for this phase:

Phase One

Inside Sherlock, we will adapt the code to support a new provider, with adjustments to the data model where necessary.

Having Sherlock and FxSuite connected will allow us to incrementally move functionalities from FxSuite to Sherlock, as well as parallel run techniques, counting FxSuite as the source of truth until the Sherlock implementation is fully functional. In this way, we will reduce the risk of such a drastic change.

After finish this phase, BOS and Salesforce still have certain responsibilities regarding screening:

  • They choose the provider they want to use. In the case where they use LexisNexis, the check will be done through the new implementation in Sherlock.
  • They control the contingency through a switch, in case ComplyAdvantage has problems and we want to use LexisNexis instead.

Phase 3

Main objective: handle contingency situations with AML providers in Sherlock.

Once phase 2 is completed, we can manage contingencies with AML providers within Sherlock itself, eliminating complexity in both BOS and Salesforce. Therefore:

  • We can deactivate a provider in Sherlock, so that all searches go through the other one as a contingency.
  • The switches on the clients will be eliminated and the process will be simplified.

In this phase we will perform also a clean up on FxSuite, removing the legacy AML functionality.

Phase 4

Main objective: integrate Sherlock with events based architecture using kafka.

We are currently reusing the existing SQS / SNS infrastructure to connect with other applications. However, once we have an event-oriented architecture we can use the new domain events to check the AML, for example when a new beneficiary is created, so we can move gradually to this new architecture.

The structure in Sherlock is as follows: Phase Four Current

So currently, ScreeningFacade receives information agnostically to the technology used, through python primitives. ScreeningFacade, depending on the type of action to be performed, instantiates one domain service or another.

When publishing, the domain services are in charge of communicating through SNS, using a connector that abstracts all the connection logic. In other words, there is no single point of control when publishing, as there is with subscriptions. In any case, regarding publishing messages, we are talking about changes in only two classes, the BaseService class from which all services inherit, and the GetSearchService class.

Therefore, the proposed solution is the following:

Phase Four New

Without going into details regarding the topic scheme, an example of the event that we publish on topic_1 would be the creation of a new beneficiary, and an example on topic_2 would be that a beneficiary-type entity has passed the AML check.

As for Sherlock, the following adjustments would be necessary:

  • Creation of a kafka consumer to subscribe to the events of certain topics that may affect screening.
  • Creation of a publisher gateway so that, as we support kafka and / or eliminate communications via SQS / SNS, we can make changes at a single point in the code, adding or removing publishings.

Roadmap beyond phase 4

Solutions to the following points will be provided either in subsequent RFCs, or by adding successive phases on this one.

AML providers management not only as contingency

After phase 3, clients still send us the provider to use in the AML check.

This option could be optional or even removed, being managed within Sherlock itself according to the policies established for this purpose (yet to be defined, hence it was not included in the scope). All the architectural changes made during the previous phases will greatly facilitate this feature.

Target Component Architecture Vision

Following the approach outlined here, the previous phases are aimed at obtaining an AML gateway for both providers. This does not conflict with the previous approach, but rather more iterations would have to be carried out to continue working on a more refined architecture as far as screening is concerned.

Alternatives

Redefine screening flows using event sourcing on earlier phases

An alternative would be to directly use the event bus (Kafka) between BOS / Salesforce and Sherlock (acting as AML Gateway), either replacing SQS / SNS, or acting as a proxy. However, this has been ruled out in this first approximation for several reasons around do not increase the scope too much:

  • The complexity of removing LexisNexis from FxSuite is high enough to don't add more substantial changes at this stage.
  • In this approach we are using the existing SQS / SNS architecture, we are not creating anything new beyond new messages.
  • For consistency, if we were to use the event bus in Kafka to communicate with LexisNexis, we should also use it for ComplyAdvantage, thereby increasing the scope considerably to update a relatively new infrastructure.
  • The use of the event bus would also imply a deeper change in the responsibilities of the clients, more oriented to event sourcing. For example, we would probably wish that instead of having to ask about the AML of a newly created beneficiary from BOS, we want to publish the event in BOS that a new beneficiary has been created, with Sherlock subscribed to created beneficiaries topic, so maybe we would need more details to the beneficiary, check the AML, and publish the event with their AML status. This detailed analysis would also increase the scope considerably because there are many situations where we would need to check the AML.

Include LexisNexis manager

We could move the connectivity with LexisNexis from FxSuite to a new service, without having to make major changes related to connectivity with the rest of the applications. For this we could create a "LexisNexis Management" service at first delivery (even before touching Sherlock):

Phase One Alternative

Their responsibilities would be:

  • Manage the connection to LexisNexis using the API that they provide us (SOAP protocol).
  • Store the requests and responses to LexisNexis in the S3 bucket allowing traceability in case of an incident, as FxSuite currently does.
  • Transform the LexisNexis response, to expose only the information necessary for the AML check, using a more friendly and cutting-edge technology (OpenAPI).

That piece finally would be moved to the final architecture:

Phase Two Alternative

To carry out that service, we could choose FastAPI for its high performance and out-of-the-box tools, as well as being a solution that we already use successfully in some services.

However, it is not very clear that this intermediate service provides enough value to be considered in the final proposal.

Caveats

As always when we work with third-party services, we will have to follow approaches and good practices that allow us to limit possible problems with them, as well as to be able to recover before a possible outage of these ones.

Operation

The AML and Sanctions team are the end users of the screening systems. This change will be transparent for them.

Monitoring

Sherlock monitoring plan is already defined here. There are detailed procedures for most common cases, like deadletter queues or ComplyAdvantage issues. We are not doing changes on our infrastructure, so the monitoring for Sherlock and the SQS will be the same, but adding cases for deadletter queues in case of LexisNexis issues.

For monitoring LexisNexis third party service, we will follow the monitoring RFC guidelines presented here.

Security Impact

Supported Versions

From January 1st, 2020 python 2.7 is no longer supported, so if people find security problems in Python 2, these will not be fixed, which could lead to a security breach in systems that use that version (like FxSuite). The same for Django, whose support ended on October 1, 2015.

Sherlock is based on supported versions (python 3.6.8 and django 2.2.17), so the security will be increased.

Decouple Salesforce and FxSuite

Salesforce is using FxSuite only as contingency for ComplyAdvantage, so if we follow the proposed solution, after phase 1, Salesforce will talk only with Sherlock.

Currently FxSuite is exposed to the world and we are just whitelisting the Salesforce IPs.

This change implies, from a security perspective, that Salesforce will not need to access to FxSuite, so FxSuite will be only an internal service, increasing the security of our current system.

Publish in SNS is a more robust and secure method compared to a direct connection to FxSuite, via HTTP API server, so as part of this project, once is fully deployed, we should remove the SF IP whitelisting in the ALB’s and the settings of FxSuite, decreasing our surface attack.

We improve our DRP’s / BCP’s regarding AML, so the tests of this redundancy should be included in the documentation.

AML high availability is a gap identified in the SEPA risk framework, with this project we resolve this issue.

Performance Impact

FxSuite will improve the performance by not having to manage the screening.

Sherlock could slightly degrade the performance because now it has to support two providers, but due to its asynchronous nature it shouldn't be a problem.

Developer Impact

We are migrating a legacy, badly structured and not documented system, in a well documented with good programming and documentation practices, so the improvement in this area will be considerable.

Also, due to the use of more updated versions of python and Django, we will be able to use new features that they provide, which are reflected in more elegant solutions using batteries included, greater versatility, etc.

Data Consumer Impact

As has been commented in the phase 1, we will use the current Sherlock architecture (SQS-SNS) to query LexisNexis (as we do currently with ComplyAdvantage). This will require adapting the data consumers. The old Fxsuite API to query LexisNexis will be removed.

Dependencies

N/A

References

Current Documentation:

Supported versions: