Skip to main content

Key Concepts

Alert​

An alert is the result of a transaction triggering one business rule. The alert is automatically created, with all known details of the transaction and any related entity as the sender or the receiver, along with indication of any business rules that were triggered. An alert might included multiple transactions (if their collective context is relevant to the triggered rule).

Alerts progress through the system, representing the ongoing investigation and data collection done by the analyst team, the reporting and compliance officers. The alert is initially assigned to an analyst who will conduct a first review. Depending on that analysis the alert might move a second review, require a formal communication to an external financial institution or be considered a normal situation that does represent fraud.

Backtesting​

Backtesting is the process of validating a business rule by applying it to historical data (past transactions handled by the system) to see how the rule would have behaved in those situations.

Backtesting will take the business rule and apply it to historic data, previously handled by the system. This will provide a more adequate baseline of the rule output, as the testing is built on real data, providing a good idea of why and how often the rule will be triggered.

Business rule​

A business rule is a set of conditions and connecting logic that TM will automatically match against any incoming transactions. The conditions define which characteristics of the transaction itself, or the intervening entities, should be examined. Characteristics might be, for example, the amount, country of origin or destination.

To complement the conditions, the connecting logic (“And”, ”Or”) defines what conditions must be met simultaneously or independently to trigger the business rule.

If any incoming transaction triggers one or more business rule, TM generates an alert per rule, so that the situation is reviewed by analysts. The alert will detail which business rule was triggered, for expediency.

It's very important that new business rules, or impactful changes to existing business rules are thoroughly tested before being activated (namely through backtesting). First, because the rule might not be correctly defined for the intended business purpose. Also, the rule conditions might need to be tuned, as not to produce too many or too few, alerts.

Once active, business rules should be periodically reviewed. Both individually or collectively. Individually to validate that the rule still matches the business needs and that the thresholds are up to date. We might also want to monitor how often the rule is triggered (resulting in an alert) and how often that leads to a false positive. Collectively, we want to make sure we have business rules covering all required business situations we want to monitor.

Entity​

Transactions are performed between two entities, the sender and receiver of the transaction. Entity information is crucial for transaction analysis. That information is sent to TM with each transaction request, but can be further expanded - for example - by defining peer groups.

TM supports three types of entities:

  • Business, for registered legal entities, such as private company or any other party with a chamber of commerce registration.

  • Individual, for a real-life individual person. Generally used for shoppers or Ultimate Beneficial Owners (UBO), the person that is the ultimate beneficiary when an institution initiates a transaction.

  • Unknown, used when the type of entity is not identifiable as business or individual. Used usually with parties in a transaction who are located outside of your payment system.

The sender and receiver entities in a transaction can be further detailed by establishing intermediaries - if applicable - through partners.

Insights​

Insights are a group of information dashboards that allow managers to find opportunities for improving performance of both the system and the analysts working with the system.

Insights provides analysis on how each business rule is performing and each team of analysts, over a configurable period of time. Access to Insights is not available to all users, being restricted to roles associated with these monitoring and managing tasks.

Partner​

Partners are optional additional entities that allow to cover transactions at a higher level of granularity for the parties involved. By adding partners, the transaction parties can be expanded from having the mandatory sender and receiver, to having one or both of those roles also defined through partners.

Partners can typically be considered as facilitators in a transaction. For example, a sending partner could be Western Union in an overseas transaction between individuals.

A Sending Partner is an entity that works as middle-man in the transaction and is in service of the sender. If a sending partner is involved, the funds are first transferred from the sender to the partner before being passed on to the receiver (or another partner and then the receiver).

A Receiving Partner is an entity that works as middle-man in the transaction and is in service of the receiver. If a receiving partner is involved, the funds are first transferred from the sender to the partner before being passed on to the receiver (or another partner and then the receiver).

Peer group​

A peer group combines a set of entities that share a set of characteristics that allows TM to draw conclusions on their expected behaviour based on their collective past behaviour and common set of characteristics. These entities might represent individuals or businesses.

Allocating an entity to a peer group allows TM to match transactions relate to that entity (as a sender or receiver) to the performance of that peer group, looking for unexpected patterns. For example, a business placed in peer group defined as coffeeshops should not receive large payments, as expenses in that type of business do not reach hundreds of Euros or Dollars. On the other hand, a business selling expensive luxury items should not be receiving small payments, or recurring daily payments. This type of different behaviour is immediately noticeable when TM has a peer group for comparison.

It’s important to allocate entities to the correct peer groups, and review the existing peer groups regularly. This helps streamline the detection performance, by making sure the expected behaviour of a peer group is not influenced by incorrectly assigned peer group members. These maintenance tasks are done through the Profiles API.

Profiles​

Profiles are sets of facts that support the rule engine, when making decisions during the rule execution, by creating a wider context for a transaction through extra information or expected behaviour for the entities participating in the transaction.

For example, peer groups are profiles that group entities, related by a common business segment, and accumulate stats (such as average transaction amount) that define an expected behaviour for that group. This allows rules to validate if the transaction fits the expectation for the entities involved, by considering their peer group.