Treasury Sciences’ Fraud Detection Engine arms you with tools to identify and defeat fraudulent behavior head-on. The Fraud Detection Engine ships with Fraud Detection models as a baseline product. As newer fraud detection models are created, they are made available to users of Treasury Sciences.. To help identify fraudulent activity, Treasury Sciences analyzes your historical data and compares current payments to historical payment patterns

Fraud Detection criteria can be configured based on multiple parameters such as user and account creation, limit management, user activity, transaction types and associated beneficiary and country of payment related information. Organizations can import payment history from their BAI files, enabling fraud detection models based on an organization's previous payment history.

Fraud Detection works in real time while incorporating patterns associated with historical data. Any transaction or administrative action (approver creation, change of limits, etc.) that meets an organization's unique criteria will be flagged and routed to authorized users. The system can be configured to either not stop payment transaction flow and allow a payment to proceed or it can require that appropriate users are alerted and notified of the flagged transaction before the payment is transmitted to the bank for payment. Because the EFT module warehouse payments before they are submitted to a bank on the value date these time windows between the origination, approval and transmission of the payment can be used to actively compare a new payment against the unique fraud detection model configured for an organization. In cases where payments that are flagged as suspect are configured to require active review; an authorized user will be required to review the transaction before it is released to the bank. Of course, the system can also be configured to not stop the payment even when fraudulent activity is suspected.

Typical rules that are setup in the system include:

• User creation, change in user’s privileges, account creation and management or any other administrative activity in the system
• Limit enhancement requests for payments
• Activity notifications on specific users, accounts or payments to a certain vendor
• Multiple or frequent payments to a specific beneficiary that do not follow normal payment patterns or history
• Payments that do not follow patterns based on organization’s history