Payments Architecture - Anti-Money Laundering Example

Cloud technology is changing the way payment services are architectured. In this series we will be presenting insight from our customers on adopting open source and cloud technology to modernize their payment service.So far we've presented research-based architectures of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.  

In the previous article in this series we walked through the immediate payments physical architecture. 

In this article we're diving into the anti-money laundering (AML) physical architecture, one based on successful customer solutions.

Architecture

As a reminder, the architectural details covered here are base on real customer integration solutions using open source technologies. 

The example scenario presented here is a generic common architecture that was uncovered researching customer solutions. It's our intent to provide guidance and not deep technical details.

This section covers the visual representations as presented. There are many ways to represent each element in this architecture, but we've chosen icons, text and colors that I hope are going to make it all easy to absorb. Feel free to post comments at the bottom of this post, or contact us directly with your feedback.

Now let's take a look at the details in this architecture and outline the example.

Anti-money laundering

The example shown on the right entitled Anti-money laundering (AML) data example outlines the solution in a physical architecture. Note that this diagram is focusing on the highest level of the AML solution and the element groupings that apply to this process.

When you look at our previous article where the immediate payments architecture was laid out as an overview, but if you look closely you'll notice one of the elements was called AML microservices. This section takes a closer look at what happens behind the scenes to a payments request that triggers a need for AML processing and detection.

In this example, starting from the top left corner, a user sends an event or message to execute a payment as an entry point. The users can be mobile, web, or any external device / application that acts as the entry point with the organizations payments architecture.

This request to execute payments connects through API gateways (not depicted) to internal centralized p ayments event streams. This element takes these streams and determines what selection or sub-selection of actions need to be taken. For this example, we'll proceed through this architecture as if AML processing is necessary.

When an event triggers a compliance issue, such as suspected money laundering, the payment transaction(s) are analysed in transaction scoring and labeling. It's a collection of rules fueled by data analytics that examine the suspect transactions, score them with a value, and tag them with labels before sending them on for specific evaluation as potential money laundering transactions.

Feeding into transaction scoring and labeling are several elements of interest that provide a bit of data, analysis, and potential for applying artificial intelligence along with machine learning concepts. This starts with know your customer (KYC) applications that are used to verify the identity, suitability, and risks involved with maintaining a business relationship with each customer. Feeding the KYC applications is data from customers and transaction data. Both of these elements are providing input to the model training and serving elements that generate models for scoring and labeling transactions.

After modeling, scoring, and labeling suspect transactions, they're sent to anti-money laundering rules, a collection of decision services that provide final evaluations and decision making on the suspect transactions. If it's determined the transactions are not money laundering actions, this outcome's fed back into the payments event stream in a topic for further clearing processing (not shown in this diagram, see the previous article for clearing and routing architectural details).

Finally, if the outcome is that the transactions are suspect, then they are passed off to the malicious activity streams element to start a topic of investigation. The actions taken are to open a case with the case management element and to start a suspicious activity reporting process. When investigations into the case and final reporting processing is completed, a reporting topic is used to funnel information back to the malicious activity streams.

The anti-money laundering architecture shown here is detailing the internal workings of the scoring, labeling, evanuation, processing, and reporting of suspect transactions. It's to be viewed as zooming in on the previous article's single element to provide more details on the physical architecture for this specific solution.

Project examples

Sharing the process results for our payments architecture is what this series is about, but there are project artefacts and diagrams that can also be shared with you the reader. We've pulled together an examples repository for all our architectural diagrams. 

The Portfolio Architecture Examples repository makes it possible to collect and share individual images from each diagram element as well as the entire project as a whole.

For example, if you scroll down to the file listings on the main page, you can locate all the example physical diagrams as shown on the right.

This is the collection associated with payments:

• in this case there are multiple images you can click to view
• a project file you can download to your local machine using the Download Diagram link
• a Load Diagram link that you can click to automatically open the project diagrams in the diagram tooling used in this architecture (use private or incognito browser mode to avoid caching issues and a smoother tooling experience) 

Give it a try and feel free to explore the collection of logical, schematic, detailed, solution, and community diagrams. This should allow you to get started much quicker than from scratch if you can kick-start a project with existing diagrams.

Should you desire to start designing your own diagrams, please contribute the project file (ending in .drawio) by raising an issue with the file attached. We'd love to continue collecting these projects for others to use.

Finally, there is a free online beginners guide workshop available focused on using the diagram tooling, please explore to learn tips and tricks from the experts.

An overview of the series on the payments portfolio architecture can be found here:

1. An introduction
2. Common architecture elements
3. Immediate payments example
4. Anti-money laundering example
5. Fraud detection example

Catch up on any articles you missed by following one of the links above.

Next in this series, taking a look at the generic fraud detection example in a cloud-native architecture focused on payment processing.