T-NEX Compliance
From uploading a regulation to issuing an audit report: T-NEX Compliance connects requirements, assessment, remediation and progress monitoring.
Learn moreProduct for regulated markets
Assess suspicious transactions faster.
T-NEX Fraud Detection connects transaction monitoring with a shared case file for fraud and AML teams. AI prepares customer and transaction context for analysis. Your team assesses the alerts, documents decisions and manages the next steps.
T-NEX Fraud Detection
From an alert to controlled case handling.
The overview, case list and rule suggestions show the analyst team's workflow.
Filter the overview
Filter the overview
The overview summarises alerts and cases by time period and typology. The next step leads into case handling.
Filtered alert and case volumes
Enlarge viewSelect a case
The case list can be narrowed by status, assignee and typology. Severity and the AI risk score remain separate information.
Prioritised case for analyst review
Enlarge viewReview a rule suggestion
An AI rule suggestion can first be created as a disabled draft. Review and backtesting precede deliberate activation.
Disabled rule draft for review and backtesting
Enlarge view In daily work
Connect suspicious transactions into actionable cases
For transaction-monitoring specialists and analysts investigating financial crime.
Incoming transactions are linked to customers and accounts. The module updates the required metrics and evaluates active rules. A match produces an alert with its typology, severity and triggering transactions. Multiple alerts for one customer are grouped into a case.
The case list shows status, priority, owner and age. The dashboard adds the distribution of alerts and outstanding cases. Automatic or manual assignment passes the case to an analyst; the highest alert severity determines the case severity.
Functions
How the application supports your team.
01
Transaction monitoring
Apply active rules to incoming transactions and retain supporting evidence.
02
Customer case file
Review alerts, customer context and supporting transactions together.
03
AI triage
Trace the score, rationale and recommendation with model and prompt version.
04
Analyst decisions
Document assignment, escalation, closure and reporting drafts with reasons.
05
Backtesting and calibration
Review historical matches before activating new rules.
06
Work through AI outages
Continue with labelled fallback text and rerun analysis after recovery.
Overview
Configure rules for the relevant patterns
The ruleset contains nine rule types. AML indicators include rapid movement, structuring, threshold breaches, high-risk jurisdictions and activity on dormant accounts. Card rules examine high transaction frequency, implausible country changes and card-testing patterns.
An additional AI rule evaluates a transaction against an instruction written in natural language. Thresholds and time windows use named parameters. The choice follows the business pattern: a clear amount or time condition does not need a model call. Country lists and thresholds are maintained and calibrated for the institution.
| Review task | Rule types | Business approach |
|---|---|---|
| AML indicators | Rapid movement, structuring, threshold breach, high-risk jurisdiction, dormant-account activity | Examine amounts, time windows, counterparties and account behaviour. |
| Card and payment patterns | Card velocity, implausible country changes, card testing | Consider temporal and geographical patterns in card context. |
| Written review instruction | AI detection rule | Apply a natural-language instruction to selected transactions. |
Overview
Assess customer and transaction context together
The case file brings together customer context, alerts and supporting transactions. It includes customer segment, risk classification, known counterparties and earlier alerts or cases. An unusual amount can therefore be examined against established behaviour and known explanations.
Rule markers explain why a transaction triggered an alert. AI triage adds a risk score, rationale and suggested action, alongside the model and prompt version used. This supports prioritisation. A score is not evidence that fraud or money laundering occurred.
Overview
Record decisions with their rationale
Analysts can assign, comment on, escalate, close or reopen a case and prepare a reporting draft. The audit trail records the action, time, analyst and rationale. A decision that differs from the AI recommendation can therefore be explained in its business context.
If the AI service is unavailable, the alert remains workable with a labelled rule-based fallback text. Analysis can be run again after recovery. Case processing therefore does not depend entirely on a successful model response.
Overview
Test rules with historical data before use
A backtest applies a rule to historical transactions without automatically creating new alerts. Transaction counts, matches and their distribution over time indicate the likely workload. Sample matches are reviewed by the business team.
AI rule suggestions can first be accepted as inactive drafts. Their purpose, parameters and historical matches are checked before activation. Reasons recorded for closed false positives support subsequent calibration. Changed rules should remain comparable; the old rule can be deactivated for that purpose.
Overview
What data does monitoring need?
The interface requires stable transaction and customer identifiers, account, currency, timestamp, amount, channel, counterparty and country. Card transactions add the relevant card attributes. Repeated transaction identifiers are used to detect duplicate deliveries.
Consistent timestamps, complete country information and delivery speed appropriate to the rule are particularly important. A short monitoring window is of little use if transactions arrive much later. These properties are checked with the upstream system and an appropriate test dataset before use.
Overview
Product brief for your project
The brief brings together scope, roles, integration questions and a suggested acceptance workflow. Use it to prepare the scope of your project.
Schematic workflow example · no real transactions
From an unusual pattern to a reviewable case decision
Several incoming payments are transferred onwards shortly afterwards. A configured rapid-throughput rule is triggered. The example shows the review process without treating the alert as proof of fraud or money laundering.
Starting point
- Stable transaction and customer identifiers
- Amount, currency, timestamp, channel, counterparty and country
- Customer context, KYC risk band and active rule parameters
Source system and interface
Receive transactions
Transactions arrive with identifiers and timestamps. Previously received transaction identifiers are rejected as duplicates.
Review and result
Review: Are identifiers, time zones and country fields complete and consistent?
Result: Transaction data that can be evaluated.
Rule engine
Record the rule hit
The active rule identifies the configured pattern and creates an alert containing the triggering transactions.
Review and result
Review: The evidence must explain why the rule was triggered.
Result: An alert with its typology, severity and supporting transactions.
AI triage
Prepare the AI assessment
The model reviews customer, account and transaction context, then provides a rationale and recommended action.
Review and result
Review: Check the model and prompt version; recognise rule-based fallback text when AI is unavailable.
Result: A recorded assessment ready for professional review.
Case management
Group into a customer case
The customer’s alerts are considered together in a case file and assigned to an analyst.
Review and result
Review: Include related alerts, previous cases and ownership.
Result: One customer case instead of isolated decisions for each alert.
Analyst
Examine context and evidence
The analyst checks the pattern against the customer profile, known counterparties and possible explanations.
Review and result
Review: Does the AI rationale hold up? Is there a credible explanation, or is further investigation needed?
Result: A reasoned assessment recorded in the action comment.
Analyst
Record the decision
In this example, the economic rationale remains unclear. The analyst records the outstanding questions and escalates the case for further review.
Review and result
Review: Ownership, reasoning and the next action must be traceable.
Result: An escalated case with an audit trail. Other outcomes include justified closure or a report draft.
The resulting work product
The rule trigger, supporting transactions, AI assessment and human decision remain traceable within the same case workflow.
An alert or AI risk score is not proof of a crime. The module does not block payments or cards. A suspicious transaction report is documented as a draft and submitted separately through the relevant reporting system.
The workflow
How we introduce the solution.
- 01
Define transaction delivery, customer links and data quality.
- 02
Select rule types and institution-specific parameters.
- 03
Review historical matches and process representative cases with analysts.
- 04
Test assignment, escalation, AI configuration and failure handling.
- 05
Activate approved rules and regularly use false-positive reviews for calibration.
What needs to be agreed before use
Alerts and AI scores are signals for investigation. The module does not guarantee a detection rate, make independent payment decisions or replace the institution’s reporting process.
FAQ
Questions about the solution
Does the module block cards or payments?
T-NEX Fraud Detection identifies and documents suspicious patterns. Card and payment blocking remain in the operational systems and their defined decision processes.
Does it automatically send suspicious-activity reports to authorities?
The module can document a reporting draft. The institution’s reporting process governs the decision, review and submission; automatic submission to an authority is not promised here.
Are the supplied thresholds legal requirements?
No. Defaults are technical starting points. Thresholds, time windows and country lists are adapted to the institution, its data and business requirements.
What happens if the AI service fails?
The case remains workable with an identifiable rule-based fallback. AI analysis can be run again when the service is restored.
How do we avoid an unmanageable number of false positives?
Before activation, we review expected match volumes and specific historical cases. During operation, closed false positives and their recorded reasons help target changes to rules and parameters.
Does the demonstration use real customer transactions?
A simulator provides synthetic data for training and demonstrations. Demo data is not used as proof of a detection rate or a production customer deployment.
Related options
You may also be interested in these.
Document extraction
Review regulations as clause trees and derive requirements with source references. Document processing within T-NEX Compliance.
Learn more
T-NEX AI Risk Manager
Connect risks, controls, processes and incidents. Explore the T-NEX AI Risk Manager product demo with AI-assisted assessment and scenario analysis.
Learn moreWhich task would you like to solve next?
Bring a concrete task. Together, we will define what the application needs to do.
Discuss a product demo