# Monitor transactions

Transaction monitoring lets you report, evaluate, and investigate payments and other financial operations in Mosaic. You can send transaction data either from a Fraud Prevention SDK session using `triggerActionEvent()` with `transactionData`, or directly from your backend using the dedicated API or orchestration journey step. In both cases, the transactions appear in **Fraud Prevention** > **Transaction Monitoring** for review and investigation.

Early availability
The dedicated backend Transaction Monitoring API and the Transaction Monitoring page in the Admin Portal are currently in early availability. Contact your Transmit Security representative for details.

Prerequisites
Transaction monitoring requires a working Fraud Prevention integration.

- **If you plan to report transactions from the client**, start with an SDK quick start such as the [JavaScript SDK quick start](/guides/risk/quick_start_web).
- **If you plan to evaluate transactions from your backend**, start with the [Backend API quick start](/guides/risk/quick_start_backendapi). Transaction evaluation integrates [Step 4](/guides/risk/quick_start_backendapi#step-4-trigger-actions) of the backend guide with a dedicated API call for financial transactions.


Transaction monitoring enables:

- **Flexible transaction reporting**: Send transaction data from the client SDK or directly from your backend, depending on your integration model.
- **Real-time transaction evaluation**: Assess payments as they occur and apply recommendations before your system completes the operation.
- **Behavioral anomaly detection**: Identify deviations from typical payer and payee activity.
- **Custom rule enforcement**: Apply business policies to influence transaction outcomes.
- **Unified visibility**: View transaction risk and decisions alongside Fraud Prevention actions in the Admin Portal.


## Choose an integration path

Transaction Monitoring supports two distinct integration paths:

- **SDK/session-based transaction reporting**: Use `triggerActionEvent()` with `transactionData` when the transaction originates in a web or mobile flow that already uses a Fraud Prevention SDK session. This path reports the transaction into Transaction Monitoring and enriches it with Fraud Prevention analysis.
- **Backend/session-less transaction evaluation**: Use the [Evaluate Transaction API](/openapi/risk/transactions.openapi) or the [Evaluate Transaction](/guides/orchestration/journeys/evaluate_transaction) journey step when you want your backend or journey to submit a transaction and receive a recommendation that your system can enforce, even without device or user session context.


These paths are closely related, but they serve slightly different integration needs:

- Both paths feed Transaction Monitoring and can be used to obtain a recommendation for a transaction.
- Choose the dedicated backend evaluation path for session-less backend integrations.


Both paths can be used before or after authentication:

- **Before authentication**: You can report the transaction with available context, such as `claimedUserId`, correlation ID, device/session context, payer, payee, and amount.
- **After authentication**: You can use the authenticated user context and any additional transaction details available in your app or backend.


## How it works

Transaction monitoring combines transaction reporting, real-time evaluation, and investigation across SDK-based and backend-driven flows.

### SDK/session-based flow

div

```mermaid
sequenceDiagram
    participant C as Client SDK
    participant B as Your backend
    participant API as Mosaic
    participant DE as Risk engine
    participant RE as Rule engine
    participant UI as Transaction Monitoring UI

    C->>API: Report transaction via <br> triggerActionEvent(..., { transactionData })
    API-->>C: Return actionToken
    C->>B: Send actionToken with <br> transaction request
    B->>API: Fetch recommendation via <br> Recommendation API
    API->>DE: Analyze transaction
    DE->>RE: Apply detection and rules
    RE-->>API: Final recommendation
    API-->>B: Return TRUST / ALLOW / <br> CHALLENGE / DENY
    API-->>UI: Surface transaction for <br> investigation
```

### Backend/session-less flow

div

```mermaid
sequenceDiagram
    participant B as Your backend / Journey
    participant API as Mosaic
    participant DE as Risk engine
    participant RE as Rule engine
    participant UI as Transaction Monitoring UI

    B->>API: Submit / evaluate transaction via <br> API or Evaluate Transaction step
    API->>DE: Analyze transaction
    DE->>RE: Apply detection and rules
    RE-->>API: Final recommendation
    API-->>B: Return TRUST / ALLOW / <br> CHALLENGE / DENY
    API-->>UI: Surface transaction for <br> investigation
```

The diagrams above show two separate integration paths into the same capability:

- In the **SDK/session-based flow**, the transaction is reported from a Fraud Prevention SDK session. The SDK returns an `actionToken`, and your backend uses that token to fetch the recommendation.
- In the **backend/session-less flow**, the transaction is submitted directly by your backend or journey and the recommendation is returned in the same evaluation flow, without requiring a device or user session context.


Evaluation combines transaction attributes, historical behavior, and real-time context:

- **Payer and payee evaluation**: Assesses the parties involved in the transaction, including their known profiles, risk attributes, and relationship to each other. This can include whether a payee is new to the payer or belongs to a higher-risk category.
- **Historical patterns**: Compares the transaction with typical behavior, such as transfer amounts, destinations, frequency, and deviations from the user's usual transaction range.
- **Real-time context**: Evaluates the current transaction as it happens, including velocity within a time window and cross-border activity involving new or higher-risk jurisdictions.
- **Rule evaluation**: Applies predefined and custom policies that can adjust or override the outcome.


Rules
Fraud Prevention evaluates transactions out of the box. To customize decisions, you can define [rules](/guides/risk/rules) based on transaction conditions such as amount thresholds, payee risk category, or jurisdiction.

If the result is `CHALLENGE` or `DENY`, your system should take action (for example, require step-up authentication or block the transaction).

## Review and manage transactions

The **Transaction Monitoring** page in the Admin Portal (**Fraud Prevention** > **Transaction Monitoring**) provides a centralized view of reported and evaluated transactions, correlated with Fraud Prevention outcomes and triggered rules. Use it to triage risky payments, investigate individual cases, and feed insights back into your detection strategy.

### Explore and filter transactions

The transactions list shows key payment details, including type, amount, parties, recommendation, and timestamp. You can sort the list and customize columns.

Use filters to narrow the list by **Time range**, **Recommendation**, **Transaction type**, **Transaction amount**, or **Advanced attributes** (transaction, payer, payee, card, device, rule, risk, or assignment data).

### Investigate a transaction

Open a transaction to review the context behind its recommendation, including risk details, payment information, session data, and related entities.

- In the **Overview**, review the main risk factors, triggered rules, payer and payee details, and payment method.
- In **Session**, check the recommendation reasons and session context, including device, browser, location, and anonymization signals.
- In **Entity Analysis**, pivot on a related user, network, or device for focused entity analysis, including recent activity and recommendation patterns.
- In **Raw Data**, inspect the full raw transaction payload when you need field-level detail.


### Act on transactions

Use follow-up actions to move from investigation to response:

- **Set label**: Tag a transaction as fraud, legit, suspected, or undetermined. See [Provide feedback with labels](/guides/risk/labels).
- **Create rule**: Start a new rule from the current transaction. For more details, see [Rules](/guides/risk/rules).
- **Assign** a transaction to a team member for review.
- **Analyze** a transaction by generating an AI-assisted summary for faster triage.
- **Share** a direct link to collaborate on a transaction.


These actions are available from the detail view and in bulk from the transactions list.

br
div
figure
a
img
figcaption
Click to open the GIF in a dedicated tab.
## Data retention

Transaction information is retained for **1 year**, allowing historical analysis, trend identification, and audit compliance across your transaction data.