Is a user logging into the system from a new device a red flag on its own? Most of the time, no. Even a high-value transfer can be a perfectly ordinary transaction when looking at the customer's past habits. However, if a new device, a different location, a newly added recipient, and a high-value transfer occur in quick succession within the same narrow time window, the picture changes completely.
Event Score Engine instantly blends all financial and non-financial events occurring in the system based on predefined rules and risk signals. Ultimately, it generates a comprehensive risk score and triggers actions such as alerts, cases, additional verification (2FA/OTP), or notification callbacks according to the institution's policy.
The main goal here is not to label every unusual activity as "fraud," but to filter out anomalous behaviors that truly require investigation within the right context.
What is an Event?
Event is any activity occurring on a user or account that can be recorded by the system. Examples of financial events include:
- Deposits and withdrawals
- Wire transfers or transactions
- Card transactions
- Balance changes
- Payment and refund activities
Non-financial events, on the other hand, are activities outside of transactions that still affect the risk assessment:
- Logging in with a new device
- IP or location changes
- Phone and email updates
- Password changes
- Identity verification results
- Adding a new recipient
- Changes in corporate partnership structure
The true value of the Event Score Engine lies in evaluating the relationship between these activities rather than looking at them individually.
How Does the Event Score Engine Work?
The process generally proceeds in four stages.
1. Event data is received: Information regarding the transaction or user activity is transmitted to the system. Fields such as amount, time, currency, user ID, device ID, IP, location, and recipient information can be included in this data. The fields to be used do not have to be the same for every institution. A bank, fintech, payment institution, or digital platform can define different events and parameters according to its own business model.
2. Rule Engine scenarios are executed: The incoming event is run through the rules defined by the institution. A simple rule might be: Create an alert if the total withdrawal amount within the last 24 hours exceeds the specified limit. A more comprehensive scenario can check multiple conditions together: Open a case if the account was opened within the last 7 days, the user logged in with a previously unseen device, and transferred funds to multiple recipients in a short period. In Truvali's Dynamic Rule & Scenario Engine structure, fields within the event can be included in the rules. Rules are not limited to fixed daily or monthly periods; custom time windows such as the last 30 minutes, the last 73 hours, or the last 15 transactions can be defined. Sender, recipient, accounts sharing a common IP, and blacklist history can be evaluated together in the same scenario.
3. Risk score is calculated: The outcome of the rules is used to determine the risk level of the event. For example, using a new device might be a low-level signal. However, if a different country, a new recipient, and unusual transaction frequency are also present within the same event, the overall risk may increase. The following information can be evaluated together when calculating the risk score:
- Customer's historical behavior
- Account age
- Transaction frequency
- Transaction time
- Device and IP information
- Recipient and sender relationship
- Previous locations
- Customer risk profile
- Watchlist or blacklist results
In this way, the system does not only answer the question "has the amount limit been exceeded?". It can also evaluate whether the transaction is typical for the customer.
4. Action is determined: Different actions can be applied based on the risk outcome of the event:
- Allowing the transaction to proceed
- Creating an alert
- Opening a case
- Requesting additional verification
- Placing the transaction under review
- Sending a Callback to the core system
Not every high risk score means the transaction is definitely fraud. The risk score indicates which events need to be examined more closely. The final process proceeds according to the institution's authorization and risk policy.
Why is a Single Transaction Not Enough?
Suspicious behaviors are often not clearly visible within a single event. For example, a customer withdrawing money might be normal. However, if immediately before the withdrawal:
- The password was changed,
- A new device was added,
- A login was made from a different country,
- A new recipient was defined,
the same transaction is evaluated differently. Therefore, a healthy risk analysis must look not only at the financial transaction but also at the events occurring before and after the transaction. In Truvali, changes in email, location, age, or corporate partnership structure can also be included in the risk assessment. The risk score can be recalculated based on financial and event-based scenarios.
How Does Truvali Add Value to This Process?
Truvali's contribution is not just assigning a score to an event. The real value lies in directly linking the risk assessment to the operational process.
Evaluates Different Events in the Same Scenario
Financial transactions, device, IP, location, user, and counterparty information can be used together. This allows signals scattered across different systems to converge into a single risk scenario.
Enables the Institution to Create Its Own Rules
The definition of normal behavior varies for every industry and institution. Instead of being bound to fixed templates, Truvali allows institutions to create their own Rule Engine scenarios.
Supports the Use of Custom Time Windows
Risk does not always emerge in daily or monthly periods. Different time intervals, such as the last 10 minutes, the last 24 hours, or the last 15 transactions, can be used.
Performs Cross-Entity Checking
The system does not only look at the user performing the transaction. Recipient history, accounts sharing a common IP, users linked to the same device, and blacklist relationships can also be checked.
Converts Risk Outcomes into Action
The outcome generated for an event can be transferred to the compliance team as an alert or case. When necessary, an action can be sent to the institution's core system via Callback.
Tests Rules Before Going Live
A new rule generating a high number of false positives can strain operations. Truvali's Rule Sandbox structure helps test the rule on historical data and foresee the volume of alerts it will generate.
A Brief Scenario Example
Let's assume a withdrawal request comes from a newly opened account. The Event Score Engine can look at the following questions:
- How old is the account?
- Has the device used been seen before?
- Which country does the IP belong to?
- How many transactions were made in the last hour?
- How much time is there between the deposit and withdrawal?
- Is the recipient linked to other suspicious accounts?
On its own, the withdrawal transaction might seem normal. However, when multiple risk signals occur simultaneously, the risk score can increase, and a case can be opened.
Frequently Asked Questions
Are the Event Score Engine and Rule Engine the Same Thing?
No. The Rule Engine determines under which conditions the event will be evaluated. The Event Score Engine, on the other hand, generates the outcome using these rules and other risk signals.
Does the Event Score Engine Only Analyze Payments?
No. Non-financial events such as device changes, IP movements, account updates, and identity verification results can also be evaluated.
Does a High Risk Score Indicate that the Transaction is Fraud?
No. A high risk score indicates that the event needs to be examined more closely. The final decision is made in conjunction with other data and the institution's policy.
Can Truvali Automatically Stop the Transaction?
A Callback can be sent to the core system based on the defined scenario. Stopping, holding, or routing the transaction to additional verification depends on the institution's integration and decision policy.