Real-time transaction monitoring
Real-time transaction monitoring is the process of evaluating and deciding on a transaction based on custom risk scenarios before it is completed. TruvaLI does not limit this evaluation to financial activity: it also scores events such as logins, device changes, and profile updates within the same engine.
The difference between real-time and batch monitoring
In batch monitoring, transactions are screened at the end of the day. By the time suspicious activity is detected, the funds have already left the institution, leaving only the obligation to report. In real-time monitoring, the evaluation is performed before the transaction is completed, and the result is returned to the core system as a decision.
This distinction is the essence of the difference between compliance and fraud prevention: compliance rules protect the institution from tomorrow's fines, while real-time decisions protect it from today's losses.
One of four decisions is returned
TruvaLI scores every event and transmits one of the following results to the core system:
- Accept: the transaction proceeds in its normal flow.
- Reject: the transaction is blocked.
- Review: the transaction is completed, but a case is opened for investigation.
- Trigger callback: a webhook is sent to the core system, for example, to request additional verification or suspend the transaction.
Decisions are returned in milliseconds. The platform is designed to operate in live environments with millions of daily transactions, ensuring business units never compromise on speed.
Non-financial events are also monitored
Risk does not only manifest in fund movements. TruvaLI incorporates events such as the following into its scenarios:
- Logins from a new device or a new IP address.
- Changes to email, phone number, or address.
- Updates to the ownership structure of a corporate customer.
- Failed login attempts and session behavior.
A high-value transfer immediately following a profile change is a classic example of two events that seem ordinary on their own but gain critical meaning when combined.
Context, not just limits
Amount thresholds like "review transactions over 50,000 TL" exist in every system, and fraudsters know these limits. What a risk-based approach requires is context.
Consecutive POS transactions from a jeweler or an appliance store at 3:00 AM do not represent a normal commercial flow, even if the amounts remain below the threshold. TruvaLI combines the merchant category code and business name with the transaction time to evaluate this as a sectoral anomaly and generate a scenario-based alert.
Works with historical data from day one
Before going live, your historical data is imported into the system. This ensures that scenarios using lookback windows, such as "in the last 6 months", "in the last 73 hours", or "in the last 15 transactions", run on real data from day one, without waiting for the system to accumulate data.
What it delivers to your institution
- The ability to intervene before losses occur.
- Both compliance and fraud scenarios running on the same engine.
- A clear record of which rule and data source drove each decision.
- New scenarios can be tested via simulation before going live.
Common questions
- What is the difference between real-time monitoring and threshold-based monitoring?
- Threshold-based monitoring only looks at the amount, and fraudsters easily learn these limits. In real-time and risk-based monitoring, the amount is evaluated alongside the context of the behavior: the customer's history, transaction time, sector, device, and counterparty relationships are also taken into account.
- What is a non-financial event and why is it monitored?
- These are events that do not involve fund movements but alter the risk profile, such as logins from a new device, email changes, or updates to the ownership structure. A significant portion of account takeover cases begin with this type of event before any funds are transferred.
- Will the transaction monitoring system affect our current speed?
- TruvaLI is designed to operate in environments with millions of daily transactions and returns decisions in milliseconds. Heavy reporting tasks are executed in the background to avoid keeping users waiting.
- When exactly is an alert generated?
- An alert is generated when an event meets the conditions of a scenario defined by the institution. The alert then becomes a structured case for investigation, showing which rule was triggered by which data within the case.