Payments Architecture - Anti-Money Laundering Example
Anti-money laundering example blueprint shown on the right entitled Anti-money laundering (AML) data example outlines the solution in a physical architec...
Join the DZone community and get the full member experience.Join For Free
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 blueprint that was uncovered researching customer solutions. It's our intent to provide a blueprint that provides guidance and not deep technical details.
This section covers the visual representations as presented. There are many ways to represent each element in this architectural blueprint, 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 blueprint and outline the example.
The example blueprint 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 blueprint 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 blueprint for this specific solution.
Sharing the process results for our payments blueprint is what this series is about, but there are project artifacts and diagrams that can also be shared with you the reader. We've pulled together an examples repository for all our architecture blueprint 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.
- 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 blueprint (use private or incognito browser mode to avoid caching issues and a smoother tooling experience)
Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.