As we mentioned recently in our post on the key factors that contribute to a great Transaction Monitoring System, or TMS for short, ensuring our customers’ funds are not involved in fraud, money laundering, or any other form of financial crime is the top priority at Devengo.

But how do we do it simply, flexibly, and robustly? Let’s explore the technical details in this post.

General design

Our TMS is conceptually modelled as a pipeline where an Evaluator takes the transaction we want to analyse and passes it down through a series of Rules to determine if they are triggered, leaving the analysis results stored in an Evaluation. To maximise flexibility, we impose a straightforward interface to those Rules. Here is a simplified version:

We ask every Rule to:

• Provide a status to know if it’s active or not (cf. “Fine-tuning the rules” below)
• Provide an action: what should happen with the analysed entity if the rule is triggered.
• Provide a description: although we have all the specific information stored, we ask the rule to provide a high-level, dynamic, human-readable description of why the rule was triggered.
• Provide a way to know if a transaction triggers the rule. The Evaluator will use this during the analysis of each Rule.

Under this simple contract, we can plug all kinds of functionality:

• Internal checks on the transaction’s specifics.
• Per customer aggregated trend analysis.
• Connection with any external services we may need for additional KYC and background checks.
• Machine learning to discover patterns in money flows, etc.

Simple

One of the unintuitive things about a TMS is that it must oversee every single transaction and, in 99% of all cases… do nothing. The overwhelming majority of the incoming/outgoing operations we monitor daily for our customers are legitimate operations that must go through without our intervention. Suspicious or problematic transactions are rare, but when they happen, we must be 100% sure we detect and manage them accordingly.

Understanding this reality, we have implemented our TMS in a way that is automatically applied without any human intervention, either on our side or our customer’s side, to every single transaction. So, there is no need to indicate any special parameters when making requests to our API. All your money flows are covered by default, all the time, every time. Simple, huh?

Flexible

Risk is by far one of the main drivers when it comes to the TMS, and good risk management requires deep knowledge of how each sector works. For an instant refund platform that serves e-commerce customers, hundreds of daily outgoing payments in the 100-150€ range and almost no incoming payments may be the norm.

However, for a crypto exchange, hundreds of 2-5K€ incoming payments and thousands of 1-2K€ payouts are another day at the office. Still, we know from our salary advance days that thousands of <50€ are the general trend in that sector.

So we want to detect suspicious transactions in all those situations -and much more- but they exhibit orders of magnitude of difference in what each one considers “normal”.

How do we technically accommodate that complexity and heterogeneity? The answer is customisation. First, we can identify outliers based on different aggregated metrics custom-defined for each customer. Each metric is a combination of timeframes, dimensions, evaluated entities and actors, giving a vast collection of monitoring possibilities. So, starting with even a simplified version of our metrics…

… we can detect a large number of suspicious trends and can easily model many rules for a specific company:

• The weekly aggregated value of incoming payments should be under 1M€
• The daily aggregated volume of outgoing payments should be under 10.000.
• The monthly aggregated value transferred to any specific IBAN should be under 700€, etc.

Transactions limits and sanctions

But that is just part of the rules we deal with. On top of these aggregated trends, using the same TMS, our compliance team can quickly establish hard limits for specific transactions based on the particular profile of our customer:

• The micro-lending platform will never lend more than 3.000€
• The insurance company’s maximum claim value is 10.000€, etc.

So, we can easily cap any transfer at that value to prevent technical mistakes, potential fraud, etc.

Additionally, we need to comply with constantly changing regulatory constraints: sanctions, watchlists, and PEP (Politically Exposed Person) lists, which may require blocking specific IBANs from any money flow. The solution? You guessed it, another TMS rule.

I could keep going with more and more controls that we can establish to better detect and prevent unexpected money flows on behalf of our customers. Still, the nice thing about the TMS we have built in Devengo is that there are plenty more controls we don’t even know about yet that we will be able to introduce uniformly and standardly in the TMS.

Robust

Another critical aspect of a good TMS is that it should be resilient and robust to be consistently applied to all and every transaction. How do we bulletproof the system to be up to those expectations?

First, we introduce the principle of erring on the side of caution. That means there are some unexpected cases where we prefer to block a false positive rather than pass a false negative. For example:

• If we consult an external sanctions list and the provider is down, we trigger the rule.
• If we are consulting an external watchlist and the provider timeouts, we trigger the rule.
• If our TMS rule code raises an error, we trigger the rule.
• If the TMS surpasses the time allocation we have given it to be computed, we trigger the rule.
• If… well, you get it.. we trigger the rule.

That lets us deal with any unexpected event in the most conservative possible way. From there, our compliance team can review the transaction and the event that triggered the rule and judge what the course of action should be based on all the information we collect.

Fine-tuning the rules

Another essential aspect of getting consistent results on production is the ability to deploy new TMS rules so that we can see their effects without applying them. It’s a testing period if you want. And that is precisely what we have implemented in our TMS.

By default, all our rules are deployed in testing mode, and although they will be included in the evaluation of each transaction, their action will not be applied.

This simple approach lets compliance see the effect a new rule will have on a customer’s transactions without impacting its business. We can even A/B test different rules to see which fits our customers’ needs better before they are activated. Being able to fine-tune the rules without impacting our customers’ businesses is another fundamental characteristic we have embedded in our TMS.

Wrapping it up

We believe there are massive challenges ahead for companies to comply with ever-tighter regulations when it comes to money movement, and these challenges will only increase in a context when instant transfers are not only a possibility but a requirement. With the TMS we have built, we look forward to meeting these challenges and working with our customers to provide the easiest AND safest experience in the market for account-to-account transfers.

Do you have any questions about transaction monitoring and the implications for your company? Let us know on LinkedIn or Twitter, we would love to hear your comments!