SYNAPSE OVERVIEW

This blog post is about Synapse - Alpha Reply's Simulation Platform that empowers Financial Institutions to test their Financial Crime control environment. You get an overview of what Synapse is all about, covering both business and technical aspects of developing such a platform.

What is Synapse?

Synapse is a platform that simulates realistic financial transactions between both retail and corporate entities to test for fraudulent activities. The financial transactions comprise both:

• Genuine transactions between two entities
• Fraudulent transactions driven by fraud or financial crime committed by one or more of the entities involved

Banks and other Financial Institutions can use Synapse to assess the performance of their control environments, through various metrics linked to the proportion of fraudulent transactions that are not being flagged by the controls in place (false negatives), as well as the proportion of genuine transactions that are mistakenly being flagged as fraudulent (false positives).

There are numerous challenges in achieving this outcome: from a functional perspective, we needed to:

• Design the mechanism for generating genuine transactions in such a way that it realistically mimics the behaviour of real agents, spanning a broad spectrum of financial and spending behaviours, whilst still displaying realistic aggregate characteristics.
• Implement fraudulent behaviours that cover a large spectrum of schemes and typologies, building on what the fraud and money laundering officers use across a large number of Financial Institutions.
• Ensure that fraudulent transactions resulting from the selected typologies are realistic and contain a degree of randomness in terms of their attributes (e.g. amount, time of the transaction, payment channel, etc…)

Design overview To meet the challenges mentioned above, we chose an Agent-Based Modelling (ABM) approach.

Synapse creates a universe of agents, each with various characteristics, and assigns the agents behaviors that drive the transactions they undertake (genuine or fraudulent). It then iteratively loops through the agents and lets them transact between themselves.

Synapse is made up of three different types of agents:

• Households contain one or more individuals, who have revenues from various sources (e.g. income, investments, others,..), and consume and invest, using products from Financial Institutions
• Corporates employ households members and generate revenues from households and other corporates with whom they transact
• Financial Institutions are corporates which, in addition, offer a range of financial products and services, such as payments, loans and investments

The output of the simulation by agents who are Financial Institutions is a list of customers (including typical KYC information) with all of their transaction history. The end-user Financial Institution represents one of the multiple Financial Institutions in Synapse's universe of agents (with its product range and customer base adjusted to the reality). The remainder of the universe is calibrated to match a broad set of characteristics of the Financial Institutions home country. Foreign country agents are simulated in a similar, albeit simplified manner.

Technical Overview

The technical implications of designing such a system are not trivial. A key consideration in building the Platform is creating a system that can scale to hundreds of millions of agents, generating and storing many billions of financial transactions over, typically several years.

We decided to use Go https://golang.org/, which appeared best placed for various reasons:

• Its concurrent programming model allows for simple and expressive architecturing of the ABM approach.
• Being strongly typed is key for a system of this complexity.
• Its syntax is less verbose than Java and allows for quick prototyping of ideas.
• It is a very fast, compiled language.
• It has a simple and robust native net library.
• Finally, it has a composition (rather than inheritance) approach to Object Oriented programming which fits perfectly with our architecture.

The most important technical design choice was to maximise the potential to run the simulations in parallel. This is a complex topic but, in a nutshell, means:

• In a first version (MVP), Synapse will run on a single server, parallelising simulations across all its CPUs.
• In a second version, and depending on how it scales on high performance servers, we will be releasing a version distributed over multiple servers.

Infrastructure and Distribution

The last area to mention is how our clients (i.e. Financial Institutions) will interact with Synapse. Our current choice is to:

• Set up a lightweight websocket server that allows our clients to launch simulation and get real-time updates (e.g. progress, logs, other economic indicators...)
• Offer both: batch storage of transactions to a user specified cloud storage and streaming of transactions through Kafka

Conclusion

This is intentionally a (very) broad yet short overview of the various aspects involved in the design and development of Synapse. As mentioned in my first post, we will be digging deeper into each of these aspects over the next few months.

If you would like to join us to improve Synapse coverage and assess how you can leverage it for your organisation, please contact us at